The condition is parsed again for every item because parser.evaluate(condition, ...) receives the source string inside the loop. At the permitted 50,000 items and 1,000-character conditions, one request can trigger tens of millions of parsing operations and become a CPU DoS vector. Parse and validate the expression once, then evaluate the parsed representation for each item's data.

Ordering comparisons pass unknown_as_literal=True, so an unknown RHS is accepted whenever the left value is also orderable as a string (for example, id > TYPO performs a lexical comparison). This contradicts the documented rule that literals are only allowed with ==/!= and can hide typos. Evaluate ordered RHS expressions without unknown_as_literal.

An in-flight evaluation can restore stale results after vulnerabilities changes: the effect clears the IDs, but the old request later resolves and calls setMatchingVulnerabilityIds. Multiple requests can also complete out of order because Enter remains active while the Apply button is disabled. Track a request generation or use an AbortController, and ignore results when the vulnerability snapshot or latest request has changed.

The matching-ID snapshot remains stored after drilling down, while TablePackages is unmounted. A subsequent vulnerability refresh therefore leaves TableVulnerabilities filtering fresh data with stale IDs. Clear filterVulnerabilityIds when the vulnerability snapshot or scope changes.